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respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 
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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 



Introduction 



The frequency bands used for broadcasting below 30 MHz are: 

• Low Frequency (LF) band - from 148,5 kHz to 283,5 kHz, in ITU Region 1 [1] only; 

• Medium Frequency (MF) band - from 526,5 kHz to 1 606,5 kHz, in ITU Regions 1 [1] and 3 [1] and from 
525 kHz to 1 705 kHz in ITU Region 2 [1]; 

• High Frequency (HE) bands - a set of individual broadcasting bands in the frequency range 2,3 MHz to 
27 MHz, generally available on a Worldwide basis. 

These bands offer unique propagation capabilities that permit the achievement of: 

• large coverage areas, whose size and location may be dependent upon the time of day, season of the year or 
period in the (approximately) 1 1 year sunspot cycle; 

• portable and mobile reception with relatively little impairment caused by the environment surrounding the 
receiver. 

There is thus a desire to continue broadcasting in these bands, perhaps especially in the case of international 
broadcasting where the HF bands offer the only reception possibilities which do not also involve the use of local 
repeater stations. 
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However, broadcasting services in these bands: 

• use analogue techniques; 

• are subject to limited quaUty; 

• are subject to considerable interference as a result of the long-distance propagation mechanisms which prevail 
in this part of the frequency spectrum and the large number of users. 

As a direct result of the above considerations, there is a desire to effect a transfer to digital transmission and reception 
techniques in order to provide the increase in quality which is needed to retain listeners who, increasingly, have a wide 
variety of other programme reception media possibilities, usually already offering higher quality and reliability. 

In order to meet the need for a digital transmission system suitable for use in all of the bands below 30 MHz, the Digital 
Radio Mondiale (DRM) consortium was formed in early 1998. The DRM consortium is a non-profit making body 
which seeks to develop and promote the use of the DRM system worldwide. Its members include broadcasters, network 
providers, receiver and transmitter manufacturers and research institutes. More information is available from their 
website ( http://www.drm.org/) . 
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Scope 



The present document gives the data application identifiers needed for Digital Radio Mondiale (DRM) system data 
applications and provides the references to the associated specifications. It provides details on data application transport 
and the mappings required to carry application specified for Digital Audio Broadcasting (DAB) in the DRM multiplex. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI ES 201 980: "Digital Radio Mondiale (DRM); System specification". 

[2] ETSI EN 301 234: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) 

protocol". 

[3] ETSI TS 101 759: "Digital Audio Broadcasting (DAB); Data Broadcasting - Transparent Data 

Channel". 

[4] ETSI ES 201 735: "Digital Audio Broadcasting (DAB); Internet Protocol (IP) datagram 

tunnelling". 

[5] ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Fast Access Channel (FAC): channel of the multiplex data stream which contains the information that is necessary to 
find services and begin to decode the multiplex 

Main Service Channel (MSC): channel of the multiplex data stream which occupies the major part of the transmission 
frame and which carries all the digital audio services, together with possible supporting and additional data services 

reserved for future addition (rfa): bits with this designation shall be set to zero 

NOTE: Receivers shall ignore these bits. 

reserved for future use (rfu): bits with this designation shall be set to zero 

NOTE: Receivers shall check that these bits are zero in order to determine the valid status of the other fields in 
the same scope. 
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Service Description Channel (SDC): channel of the multiplex data stream which gives information to decode the 
services included in the multiplex 

NOTE: The SDC also provides additional information to enable a receiver to find alternative sources of the same 
data. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CRC Cyclic Redundancy Check 

DAB Digital Audio Broadcasting 

DRM Digital Radio Mondiale 

FAC Fast Access Channel 

HF High Frequency 

LF Low Frequency 

MF Medium Frequency 

MOT Multimedia Object Transfer 

MSC Main Service Channel 

rfa reserved for future addition 

rfu reserved for future use 

SDC Service Description Channel 

TDC Transparent Data Channel 



4 General 

DRM has been designed to provide transport mechanisms for data applications which are complimentary to the audio 
service(s) carried or which stand alone. For stand alone data services, the FAC contains an application identifier field 
which allows receivers to scan the frequency bands to find a particular data service. For all data applications, the SDC 
data entity type 5 - application information - shall be coded according to ES 201 980 [1] and the descriptions provided 
in the present document. 

The DRM multiplex may contain up to four streams in the MSC, each carrying audio or data service information. 

Using the SDC data entities type 9 and/or 5, each DRM service can reference: 
one audio stream, 

one data stream (or one data sub-stream if the stream is in packet mode), or 
one audio stream and one data stream (or one data sub-stream) as programme associated data. 



4.1 New data applications 



As new data applications are defined and standardized, the present document will be revised to reflect those changes. 
The content of the present document is maintained by the DRM Consortium. Applications for the inclusion of a new 
data application should be made to the address below: 

Digital Radio IVIondiale 
DRIVI Project Office 
Postal Box 360 
CH - 1218 Grand-Saconnex 
Geneva - Switzerland 
Tel: +41 22 717 2718 
Fax: +41 22 747 4718 
E-mail: applications@drm.org 
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Applications for the inclusion of a new data application shall clearly state the purpose along with all necessary 
definitions of required fields. Support from other organizations for the request should be cited. The proposal shall be 
circulated to all members of the DRM consortium for a 30 day comment period. If there are no adverse comments, then 
the application, as amended by any helpful editorial suggestions will be accepted and published within a further 30 days 
on the DRM website. If there are adverse comments, then the application will be considered by the DRM Technical 
Committee at its next plenary meeting following the comment period. The applicant will be given an opportunity to 
describe their proposal and reasons for it. The decision of the DRM Technical Committee will be final and if the 
application is accepted, as amended by any helpful editorial suggestions, it will be published within 30 days on the 
DRM website. The present document will be amended as required via the normal ETSI process. 



4.2 FAC Application identifiers 



The FAC service information contains a field to indicate the data application identifier. This is to allow a scanning 
receiver to quickly decide if the application is useful or whether to continue to scan. 

The application identifier is only available to stand alone data services, not data applications carried with audio services. 

Table 1 provides the interpretation of the application identifier field. 

Table 1 : Application identifiers 



Decimal number 


Application identifier 





application is only signalled in the SDC 


1 to 30 


reserved for future definition 


31 


skip indicator 


NOTE 1 : The value shall be used for proprietary applications. 
NOTE 2: The skip indicator is to allow for engineering test 
transmissions to be ignored by standard receivers. 



4.3 SDC application information data entity - type 5 

The SDC data entities are defined in ES 201 980 [1]. The application information data entity - type 5 - contains various 
fields for which the interpretations are defined in the present document. 

All data services (or data applications for audio services) are described by data entity type 5. Many applications may 
require additional data to describe them that is specific to that application. 

bit# 



12 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36... 




1 1 1 


ShtID 


StrlD 


PM 




! ! 







rfa 


EF 


AppDom 











DRM AppID 


app data fields ... 




1 


rfu DAB AppID 


app data fields ... 






2-7 


rfu ... 
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DU 


PID 


EF 


AppDom 


; ; 









PLen 


DRM AppID 


app data fields ... 




1 


PLen 


rfu 


DAB AppID 


app data fields ... 


2-7 


PLen 


rfu ... 














general field type 






defined field value 



Figure 1 : SDC data entity type 5 bit scheme 

Figure 1 shows the various combinations for the data entity type 5 fields. The abbreviations used are defined as follows: 



ShtID: 


Short ID 


StrlD: 


Stream ID 


PM: 


Packet Mode indicator 
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EF: 


Enhancement Flag 


DU: 


Data Unit indicator 


PID: 


Packet ID 


PLen: 


Packet Length 


AppDom: 


Application Domain 



DRM AppID: user application identifier for DRM specified data Applications 

DAB AppID: user application type for DAB specified data Applications 

app data fields: data fields as required by individual application specification (length depends on application) 

rfa/rfu: fields shall be set to 

4.3.1 Application (domain 

The application domain field is a 3-bit field. Table 2 provides the interpretation of the application domain field. 

Table 2: Application domains 



Decimal number 


Application domain 





DRM 


1 


DAB 


2 to 7 


reserved for future definition 



4.3.2 Application data 

The application data field is a variable length field defined by the application domain and the data application 
specification. 

4.3.2.1 Application domain DRM 

When the application domain carries the value (DRM), the application data field shall be made up as follows: 

user application identifier 16 bits 

application data m bytes 

user application identifier: this field shall indicate the user application identifier as follows: 

The values 0x0000 to 0x7FFF are reserved for openly specified applications. 

The values 0x8000 to OxFFFF are reserved for proprietary applications. 
application data: as required by the corresponding DRM application specification. 

4.3.2.2 Application domain DAB 

When the application domain carries the value 1 (DAB), the application data field shall be made up as follows: 

rfu 5 bits 

user application type 1 1 bits 

application data m bytes 

rfu: these 5 bits shall be reserved for future use by the application data field and shall be set to zero until they are 
defined. 

user application type: the value specified in TS 101 756 [5]. 

application data: as required by the corresponding DAB application specification. 

4.3.2.3 Undefined application domains 

When the application domain carries a value other than or 1, the application data field is reserved for future definition. 
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4.4 Transport protocol signalling 

Every data application shall clearly state which of the transport mechanisms shall be used: 
DRM domain applications shall use the mechanisms detailed in clause 5. 
DAB domain applications shall use the mappings provided in clause 6 to the mechanisms detailed in clause 5. 



DRIVI data transport 



Data essentially comes in two types - streams and objects (files). DRM provides the basic mechanisms to transport these 
two types of data. 

5.1 Streams 

Data stream transport has three varieties in DRM: 

synchronous stream mode; 

asynchronous stream mode; 

asynchronous data unit mode. 

The synchronous stream mode occupies a full DRM data stream. Therefore the bitrate is fixed until a multiplex 
reconfiguration occurs. 

The two asynchronous modes allow the transport of streaming data without a fixed bitrate. Whenever new data is 
available at the transmitting side it will be forwarded to the receiving DRM application decoder. 



5.1 .1 Synchronous stream mode 



In this mode a data stream of fixed bitrate is broadcast. When there is no data to send, the multiplex encoder shall 
transmit Obits. 

This mode is signalled by setting the following parameters in SDC data entity type 5 (see ES 201 980 [1]): 

The packet mode indicator is set to to indicate synchronous stream mode. 

5.1 .2 Asynchronous stream mode 

In this mode a data stream of variable bit rate is broadcast. 
The benefits of this low level implementation are: 

low overhead; 

low latency; 

simple processing requirements. 
This mode is signalled by setting the following parameters in SDC data entity type 5 (see ES 201 980 [1]): 

the Packet mode indicator bit is set to 1 to indicate packet mode; 

the Data unit indicator bit is set to to indicate single packets. 
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5.1 .3 Asynchronous data unit mode 

In this mode a data stream of variable bit rate is broadcast. 

The benefits of this scheme in comparison to asynchronous stream mode are: 

error control by using data unit repetition; 

the ability to guarantee that "chunks" of data from the stream are delivered to the receiver (or lost) as a 
coherent set of data. 

This mode is signalled by setting the following parameters in SDC data entity type 5 (see ES 201 980 [1]): 

the Packet mode indicator bit is set to 1 to indicate packet mode; 

the Data unit indicator bit is set to 1 to indicate data units. 



5.2 Objects (files) 



For the standardized transport of objects, DRM uses the DAB MOT protocol EN 301 234 [2]. There is a simple 
adaptation that is applied which is described below. 

5.2.1 IVIOT - Introduction 

The MOT protocol allows finite objects to be carried from the broadcaster to the receiver. It provides reliable and 
consistent transfer of objects, each up to 256 MBytes in size. 

In addition to the payload (e.g. a file), management data can be broadcast: file name, file size, content type, etc. 

Figure 2 shows how a MOT data group is built from a given payload, e.g. a file. 



File 



Header core Header extension Body segment 1 Body segment 2 



Body segment n 



Segmentation 
header 



Segment 



Segmentation 
(leader 



Segment 



I\/1SC data Session 
group (leader ineader 

MSC Data Group Type 3 



IVISC data group l\/ISC data 
data field group CRC 



MSC data Session MSC data group 
group header header data field 

MSC Data Group Type 4 or 5 



MSC data 
group CRC 



Figure 2: MOT segments and data groups 

In the first step, a MOT header is created to describe the MOT body (in this example a file). The MOT header contains 
the MOT object's management data. Afterwards, the MOT header as well as the MOT body are split into equally sized 
segments (only the last segment of each item may be smaller). 

Note that the headers of several files may be combined and sent as a separate MOT Directory using MSC Data Groups 
Type 6. This is called "MOT Directory mode" and allows proper management of several concurrent objects. When only 
a single object is required, the directory is not needed and "MOT Header mode" may be used. 
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Segmentation is especially useful if only one series of packets can be transported at a time in combination with low bit 
rates, as it is the case for DRM packet mode. If each file had to be sent as one piece, large files would occupy the DRM 
channel for a very long time. By using segmentation, only one segment of the file has to be sent in one piece. Segments 
of other MOT objects may be sent interleaved. This allows the transport of MOT objects with higher priority at a 
virtually higher bit rate. Segments of larger, less important objects can therefore be sent at a virtually lower bit rate. 

The segments are each mapped into one DAB MSC data group. The DAB MSC data group is the lowest level of the 
MOT protocol. For transporting files using the MOT protocol in DRM, the mapping from the DAB MSC data groups to 
DRM is given in the following clause. 

5.2.2 MOT over DRM 

For DRM, each DAB MSC data group is mapped directly to a DRM data unit. The DRM data unit is split into packets 
of any suitable size and transported using the DRM Packet Mode protocol (as specified in ES 201 980 [1]). Figure 3 
shows this procedure. "FF" and "LF" represent the state of the "first flag" and "last flag" bits for each packet. 



MSC data Session 
group header header 



MSCdata group 
data field 



IVISCdata 
group CRC 



Dl^ Data Unit 




data 2 



CI=C2 



lidrN 



data N 



CRCN 



packet 1 (FF^LF=10J 



pacl<et 2(FF,LF=00J 

Figure 3: MSC data group transport in DRIUI 



packet N(FF^LF=01J 



This is almost equal to the DAB procedure. All levels of en- and decoding, starting with the MSC data group and above, 
remain exactly as they were specified for MOT. 



Data applications 



Data applications are divided into various categories, depending upon the domain in which they were specified. The 
SDC data entity 5 carries information on which domain and the following clauses describe the applications that are 
specified for use in DRM. Some applications have an entry in the FAC application Id table and so can be selected from 
scanning through the frequencies. These applications are specified in clause 4.2. 

6.1 DRM domain applications 
6.1.1 Openly specified applications 

There are currently no openly specified data applications registered. 

Table 3: Application identifiers for openly specified applications 



Application identifier 


Name of application 


Reference document 


0x0000 


Reserved 






Reserved 




0x7FFF 


Reserved 
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6.1 .2 Proprietary applications 

There are currently no proprietary data applications registered. 

Table 4: Application identifiers for proprietary applications 



Application identifier 


Name of holder 


Date of issue 


0x8000 


Reserved 






Reserved 




OxFFFF 


Reserved 





6.2 DAB domain applications 

6.2.1 General 

All DAB data applications that use the TDC, the MOT, or IP tunnelling can be carried in a DRM multiplex. However, 
the signalling shall be carried solely in the SDC except for applications with an entry in the FAC table where both FAC 
and SDC carry the signalling information. For a complete list of DAB data applications see TS 101 756 [5]. 

6.2.2 Signalling 

In DAB, applications are signalled using FIG 0/13. In DRM, the application specific signalling data is carried in SDC 
data entity type 5 as specified by ES 201 980 [1] and clause 4.3 of the present document. 

6.2.3 Applications using the Transparent Data Channel (TDC) 

DAB defines the TDC as general purpose transport protocol for use by data applications requiring simple streaming 
data to be delivered from service provider to receiver. It is standardized as TS 101 759 [3]. 

TS 101 759 [3] defines three methods for transporting data application streams. Two of these, namely TDC in a packet 
mode service component and TDC in stream mode service component, are applicable to the DRM Multiplex. The third 
method, TDC in an audio stream service component using X-PAD, is not applicable. 

6.2.3.1 TDC in a packet mode service component 

This method is used to transport asynchronous data streams, either with or without the use of DAB MSC data groups. 
DRM packet mode ES 201 980 [1] is used as the transport mechanism in DRM, either with or without the use of DRM 
data units. 

6.2.3.1 .1 TDC in a packet mode service component without data groups 

This is carried as asynchronous stream mode, see clause 5.1.2. The application data is carried in packets. 

The Packet mode indicator is set to 1 to indicate packet mode. The Data unit indicator is set to to indicate DRM data 
unit transport is not used. 

6.2.3.1 .2 TDC in a packet mode service component with data groups 

This is carried as asynchronous data unit mode, see clause 5.1.3. Each DAB MSC data group is mapped directly to a 
DRM data unit. The DRM data unit is split into packets of any suitable size and transported using the DRM Packet 
Mode protocol (see ES 201 980 [1]). Figure 2 shows this procedure. 

The Packet mode indicator is set to 1 to indicate packet mode. The Data unit indicator is set to 1 to indicate DRM data 
unit transport is used. 

In this mode, end user addressing is available. 
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6.2.3.2 TDC in a stream mode service component 

This method is used to transport synchronous data streams (fixed bit rate). 
This is carried in DRM as synchronous stream mode, see clause 5.1.1. 
The Packet mode indicator is set to to indicate stream mode. 

6.2.4 Applications using tine Multimedia Object Transfer protocol (MOT) 

The MOT protocol (EN 301 234 [2]) is specified for use with DRM. The mapping from DAB data groups to DRM data 
units is specified in clause 5.2. 

6.2.5 Applications using IP tunnelling 

The IP Packets including their respective IP Headers are mapped into one DAB MSC Data Group each. This adds 
another protection mechanism by introducing a CRC checksum and allows the retransmission of IP Packets. 

This mechanism is described in ES 201 735 [4]. 

For transmission over DRM, the DAB MSC Data Groups are mapped to DRM Data Units as described in clause 5.2.2. 
The DRM data units are transmitted in asynchronous data unit mode, see clause 5.1.3. 
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